home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / hacklist / 94-05 / text0011.txt < prev    next >
Encoding:
Text File  |  1994-05-19  |  4.5 KB  |  95 lines
  1. >> It sort of sounds like you're agreeing with me, that the FD_CLOSE is
  2. >> unnecessary after the closesocket.  I think the statement that closesocket
  3. >> cancels async notifications takes precedence, and if an app really needs
  4. >> to find out if the connection closed gracefully, it should hang onto the
  5. >> descriptor, use shutdown(1) to send a FIN, then read to EOF.
  6.  
  7. This seems reasonable and correct to me.
  8.  
  9. -- 
  10. Brad Wilson    Share and Enjoy!    Voice: (800)282-4FTP   Fax: (508)659-6297
  11. Not speaking for FTP Software, Inc.      Internet: wilson@ftp.com     msg++;
  12.    "i am the bullet in the gun / i am the truth from which you run
  13.     i am the silencing machine / i am the end of all your dreams"  - NIN
  14. From rcq@mailserv-D.ftp.com Wed May  4 13:53:43 1994
  15. Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  16.           id AA23846; Wed, 4 May 1994 17:55:02 -0400
  17. Received: from ftp.com by ftp.com  ; Wed, 4 May 1994 17:54:58 -0400
  18. Received: from mailserv-D.ftp.com by ftp.com  ; Wed, 4 May 1994 17:54:58 -0400
  19. Received: from rcq.sidearm.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
  20.     id AA23621; Wed, 4 May 94 17:53:43 EDT
  21. Date: Wed, 4 May 94 17:53:43 EDT
  22. Message-Id: <9405042153.AA23621@mailserv-D.ftp.com>
  23. To: Bruce@isi.FrontierTech.COM
  24. Subject: Re: FD_CLOSE after closesocket (was: Curious behaviour from winsock)
  25. From: rcq@ftp.com  (Bob Quinn)
  26. Reply-To: rcq@ftp.com
  27. Cc: Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
  28. Sender: rcq@mailserv-D.ftp.com
  29. Repository: mailserv-D.ftp.com, [message accepted at Wed May  4 17:53:29 1994]
  30. Originating-Client: sidearm.ftp.com
  31. Content-Length: 2927
  32.  
  33. >  It sort of sounds like you're agreeing with me, that the FD_CLOSE is
  34. >  unnecessary after the closesocket.  I think the statement that closesocket
  35. >  cancels async notifications takes precedence,
  36.  
  37. So we're faced then with either having the spec say that:
  38.   - FD_CLOSE doesn't occur *at all* on a socket that initiates the close
  39.      (with shutdown() or with closesocket()), since in effect it just
  40.      tells you something you already know.
  41.                                    OR
  42.   - FD_CLOSE does *not* occur after calling closesocket() to initiate the
  43.      close of a TCP connection, but it *does* occur after calling shutdown()
  44.  
  45. That's about as transparent as my cafe latte.
  46.  
  47. > and if an app really needs
  48. >  to find out if the connection closed gracefully, it should hang onto the
  49. >  descriptor, use shutdown(1) to send a FIN, then read to EOF.
  50.  
  51. I couldn't agree with this more.  The problem is that most people
  52. don't know this method, as evidenced by most WinSock applications
  53. around these days.
  54.  
  55. >  IMHO,
  56. >  calling closesocket says "I am done with this socket, and have no further
  57. >  interest in anything associated with it."
  58.  
  59. I agree, but I don't want to.
  60.  
  61. As is, the specification says this, yes.  IMNSHO, you *should*
  62. be able to post a message (FD_CLOSE only, not FD_READ or others)
  63. for a socket that has been closed by closesocket().  As we all
  64. know, every application is *required* to expect receipt of messages
  65. on a socket even after the socket has been closed.  This is because
  66. of the latency between the posting and receipt of messages.  In
  67. other words, there is always the chance of as yet unprocessed
  68. messages in your queue when you call closesocket().
  69.  
  70. So what?  So, I (still) think that FD_CLOSE is broken if it doesn't
  71. tell you when you reach TIME_WAIT instead of CLOSE_WAIT.  WinSock
  72. should indeed tell you when the close is complete.  Not just cuz
  73. I like the warm and fuzzy feeling I get knowing a connection closed
  74. gracefully, but also because it's easy to write an application that
  75. works with this and it satisfies my insatiable desire for a logical
  76. and symmetrical world (which is--amazingly enough--possible in the
  77. computer software realm).
  78.   
  79. >  I still maintain that closesocket invalidates the descriptor and what
  80. >  would an app do if it didn't get the FD_CLOSE it expected?  Reset the
  81. >  connection?  It can't, because it has no reference to the connection now
  82. >  that the socket descriptor is gone.   It might display a warning to the
  83. >  user, but since it can't take any meaningful steps to correct the problem,
  84. >  this would amount to "I've fallen, and I can't get up!"
  85.  
  86. As much as I like that error message, I think it might be more
  87. meaningful to a user to say something like "the connection on
  88. the remote host was disconnected unexpectedly".
  89.  
  90. Regards,
  91. --
  92.  Bob Quinn                                             rcq@ftp.com
  93.  FTP Software, Inc.                                No. Andover, MA
  94.  
  95.